2. 다양한 고수준 런타임

4.2 다양한 고수준 런타임 (도커 호환 런타임)

4.2.1 도커 (Docker)

도커의 위치:

도커는 고수준 런타임에 해당함. 고수준 런타임 정의에는 여러 시각이 있어서 도커를 구성하는 컴포넌트인 containerd를 고수준 런타임으로 보고 도커를 그 위에 위치한 엔진으로 보는 경우도 있음

도커 아키텍처:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[사용자]
    │
    │ docker run, docker build, docker push
    ↓
[Docker CLI]
    │
    │ REST API
    ↓
[Docker Daemon (dockerd)]
    │
    ├─ 이미지 빌드 (docker build)
    ├─ 레지스트리 통신 (docker push/pull)
    ├─ 컨테이너 관리
    ├─ 네트워크 관리
    ├─ 볼륨 관리
    └─ 스웜 모드 (오케스트레이션)
    │
    │ containerd API
    ↓
[containerd]
    │
    │ OCI Runtime 호출
    ↓
[runc]
    │
    ↓
[컨테이너]

도커의 특징:

도커는 컨테이너 실행뿐만 아니라 컨테이너 빌드 기능 등 다양한 기능을 제공하고 컨테이너 작업 흐름 전체를 관리할 수 있는 도구로 쓰임

4.2.2 파드맨 (Podman)

파드맨이란?

파드맨은 레드햇을 중심으로 개발된 도구로 컨테이너 작업 흐름을 포괄적으로 관리할 수 있음. 도커 호환 CLI를 제공하는 컨테이너 런타임으로 레드햇을 중심으로 오픈소스로 개발을 진행함

파드맨 아키텍처:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[사용자]
    │
    │ podman run, podman build, podman push
    ↓
[Podman CLI]
    │
    │ 직접 OCI 런타임 호출 (데몬 없음!)
    ↓
[conmon (Container Monitor)]
    │
    ├─ 각 컨테이너마다 conmon 프로세스 생성
    ├─ 컨테이너 입출력 관리
    └─ 로그 수집
    │
    ↓
[OCI 런타임 (runc, crun)]
    │
    ↓
[컨테이너]

도커 vs 파드맨 아키텍처 비교:

아키텍처 비교:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[Docker - 클라이언트/서버 아키텍처]

    사용자 A ─┐
              │    ┌──────────────┐
    사용자 B ─┼───► │ dockerd      │───► 컨테이너들
              │    │ (공통 데몬)   │
    사용자 C ─┘     └──────────────┘

    특징:
    ├─ 공통 데몬(dockerd)이 모든 컨테이너 관리
    ├─ root 권한으로 실행되는 데몬 필요
    └─ 데몬 장애 시 모든 컨테이너 영향

vs

[Podman - 데몬리스 아키텍처]

    사용자 A ───► podman ───► conmon A ───► 컨테이너 A

    사용자 B ───► podman ───► conmon B ───► 컨테이너 B

    사용자 C ───► podman ───► conmon C ───► 컨테이너 C

    특징:
    ├─ 공통 데몬 없음 (데몬리스)
    ├─ 컨테이너마다 독립적인 conmon 프로세스
    ├─ 루트리스(rootless) 컨테이너 지원
    └─ 한 컨테이너 장애가 다른 컨테이너에 영향 없음

파드맨의 주요 특징:

쿠버네티스 매니페스트 지원:

파드맨은 여러 컨테이너를 하나로 묶어서 실행하는 파드 기능이 있음. 쿠버네티스의 파드와 디플로이먼트 매니페스트를 파드맨에서 실행하거나, 반대로 파드맨의 파드와 컨테이너를 쿠버네티스에서 실행하기 위한 매니페스트를 생성하는 등의 쿠버네티스 매니페스트를 지원하는 기능도 제공함

파드맨 ↔ 쿠버네티스 연동:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[Podman → Kubernetes]
    │
    podman generate kube <pod-name>
    ↓
    쿠버네티스 매니페스트 (YAML) 생성

[Kubernetes → Podman]
    │
    podman play kube <manifest.yaml>
    ↓
    쿠버네티스 매니페스트로 파드맨에서 파드 실행

4.3. 다양한 고수준 런타임 (CRI 런타임)

4.3.1 containerd

containerd란?

containerd는 CNCF에서 개발하는 컨테이너 런타임임. containerd는 CRI 구현체이며 EKS, AKS, GKE 등에서 사용함. 원래는 도커의 일부였지만 현재는 독립 프로젝트로 개발이 진행됨

containerd 위치:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[도커에서의 containerd]
    │
    Docker Daemon (dockerd)
    ↓
    containerd    ← 도커 내부에서 사용
    ↓
    runc
    ↓
    컨테이너

[쿠버네티스에서의 containerd]
    │
    kubelet
    ↓
    containerd    ← CRI 런타임으로 직접 사용
    ↓
    runc
    ↓
    컨테이너

containerd의 플러그형 설계:

플러그형 설계가 특징이며, 사용 사례에 따라 플러그인을 구현해 containerd를 확장할 수 있음

containerd 플러그인 아키텍처:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[containerd 코어]
    │
    ├─ CRI 플러그인
    │  └─ kubelet과 통신
    │
    ├─ 이미지 플러그인
    │  ├─ stargz-snapshotter (이미지 풀 고속화)
    │  └─ soci-snapshotter (AWS Fargate용)
    │
    ├─ 런타임 플러그인 (shim)
    │  ├─ containerd-shim-runc-v2 (runc용)
    │  ├─ containerd-shim-kata-v2 (Kata Containers용)
    │  └─ 커스텀 shim
    │
    └─ 스토리지 플러그인
       └─ overlayfs, btrfs, zfs 등

shim 플러그인:

containerd는 저수준 런타임을 shim 플러그인을 통해서 인식함. 저수준 런타임 프로젝트는 각자 설계에 맞춰서 shim을 구현하기 때문에 containerd를 통해 저수준 런타임을 조작할 수 있음

containerd 클라이언트:

containerd는 CRI와 다른 containerd API와 클라이언트 라이브러리를 제공함. 이를 통해 쿠버네티스에서만 사용할 수 있는 것이 아니라 다른 도구도 클라이언트 라이브러리를 사용해 containerd를 사용할 수 있음

containerd 클라이언트들:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[containerd API / 클라이언트 라이브러리]
    │
    ├─ Docker
    │  └─ 컨테이너 관리를 위해 내부적으로 사용
    │
    ├─ BuildKit
    │  └─ 이미지 빌드 도구 (moby 프로젝트)
    │
    ├─ nerdctl
    │  └─ 도커 호환 CLI (containerd 서브 프로젝트)
    │
    └─ kubelet (via CRI)
       └─ 쿠버네티스 노드 에이전트

4.3.2 CRI-O

CRI-O란?

CRI-O도 CNCF에 속한 컨테이너 런타임으로 Kubernetes Node SIG와 레드햇을 중심으로 개발이 진행됨. CRI-O는 쿠버네티스가 직접 사용할 목적으로 개발된 것이 특징임

CRI-O 아키텍처:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[kubelet]
    │
    │ CRI (gRPC)
    ↓
[CRI-O]
    │
    ├─ 이미지 관리 (containers/image)
    ├─ 스토리지 관리 (containers/storage)
    ├─ 네트워크 관리 (CNI)
    │
    │ OCI Runtime 호출
    ↓
[conmon (Container Monitor)]
    │
    ├─ 각 컨테이너마다 conmon 프로세스
    ├─ 입출력 관리
    └─ 로그 수집
    │
    ↓
[OCI 런타임 (runc, crun)]
    │
    ↓
[컨테이너]

containerd vs CRI-O 비교:

CRI-O의 특징:

CRI를 통해서 사용하지 않는 기능(이미지 빌드, 레지스트리 푸시 기능 등)은 개발 범위에서 제외되고 버전도 쿠버네티스를 따라감

CRI-O 버전 정책:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Kubernetes 1.28  →  CRI-O 1.28.x
Kubernetes 1.29  →  CRI-O 1.29.x
Kubernetes 1.30  →  CRI-O 1.30.x

특징:
├─ 쿠버네티스 메이저/마이너 버전과 동일
├─ 쿠버네티스와 호환성 보장
└─ 쿠버네티스에 불필요한 기능 제외

containers 조직 라이브러리:

설계 측면에서는 containerd와 다르게 플러그인을 지향하지 않지만 스토리지나 이미지 관련 주요 컴포넌트가 각자 독립적인 라이브러리 프로젝트로 개발되는 점이 특징임. 이런 프로젝트는 깃허브 containers 조직 하위에 존재함

containers 조직 라이브러리:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[github.com/containers]
    │
    ├─ containers/image
    │  └─ 이미지 관리 라이브러리
    │
    ├─ containers/storage
    │  └─ 스토리지 관리 라이브러리
    │
    ├─ containers/common
    │  └─ 공통 유틸리티
    │
    └─ 사용하는 프로젝트:
       ├─ CRI-O
       └─ Podman (일부 코드 공유)

CRI-O도 파드맨과 마찬가지로 각 컨테이너 관리를 conmon 프로세스를 사용해서 각 컨테이너 입출력 관리와 로그 수집 작업을 함

고수준 런타임 비교 정리

전체 비교표:

런타임 선택 가이드:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[로컬 개발 환경]
    │
    ├─ Docker Desktop
    │  └─ 가장 보편적, 풍부한 기능
    │
    └─ Podman
       └─ 데몬리스, 루트리스, 보안 강화

[쿠버네티스 클러스터]
    │
    ├─ containerd
    │  └─ EKS, AKS, GKE 기본 런타임
    │     범용적, 플러그인 확장 가능
    │
    └─ CRI-O
       └─ OpenShift 기본 런타임
          쿠버네티스 전용, 미니멀

참고 자료

공식 문서:

• Docker: https://docs.docker.com/
• Podman: https://podman.io/
• containerd: https://containerd.io/
• CRI-O: https://cri-o.io/
• nerdctl: https://github.com/containerd/nerdctl

GitHub:

• containers 조직: https://github.com/containers
• containerd: https://github.com/containerd/containerd
• CRI-O: https://github.com/cri-o/cri-o